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Object-oriented programming laws have been proposed in the context of languages that are not com- 
bined with a behavioral interface specification language (BISL). The strong dependence between 
source-code and interface specifications may cause a number of difficulties when transforming pro- 
grams. In this paper we introduce a set of programming laws for object-oriented languages like Java 
combined with the Java Modeling Language (JML). The set of laws deals with object-oriented fea- 
tures taking into account their specifications. Some laws deal only with features of the specification 
language. These laws constitute a set of small transformations for the development of more elaborate 
ones like refactorings. 

1 Introduction 

Software changes constantly due to maintenance that leads to correction of fails or just to improve func- 
tionalities. However, some changes can take place to achieve quality factors like reuse and legibility. In 
these cases, changes should not alter the software behavior but only its internal structure. Improving the 
internal software structure is an activity known as refactoring [8]. To avoid errors due to modifications, 
every change has to be done following a discipline. 

This discipline can be achieved by programming laws, as guidelines to informal programming prac- 
tices, establishing a basis for formal and rigorous program development. They are largely known for 
imperative programming |[T2l[T9Tl . Also, functional programming and logic programming have a set of 
laws described by Bird and de Moor [2] and Seres lEUl , respectively. Laws of object-oriented program- 
ming have also been addressed in [3] [71 HI. 

Design by Contract (DbC) |[T8l is a development methodology that aims at the construction of reliable 
object-oriented systems. Its basic idea is that a contract is established among classes of a system. In this 
way, software developers should formally specify what is required and ensured by methods and types. 
The Java Modeling Language (JML) lfl6l IT4l is a notation for formally specifying the behavior of Java 
classes and methods. 

The set of programming laws for object-oriented programming we have nowadays is designed for 
program transformation with no relation to specifications languages designed for DbC. Changes in spec- 
ification usually should discharge code updates, maintaining the conformance between code and spec- 
ification. On the other hand, changes in program code may require changes in specifications as the 
behavior implemented by code may diverge from the meaning of the original specification. For instance, 
moving a redefined method to its superclass can be illegal if this transformation causes weakening of 
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1 public class PositivelntegerData { 

2 //@ private invariant value . intValue () > -1; 

3 private Integer value; 

4 public PositivelntegerDataQ { value = new Integer(O); } 



6 



/*@ requires newValue != null && newValue. intValueQ > -1; 

@ ensures getValueQ . intValue() == newValue . intValue () ; @*/ 
public void regi sterValue( Integer newValue) { /* ... */ } 
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//@ ensures \result != null; 

public /*@ pure @*/ Integer getValue() { /* 



V I 
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/*@ requires getValue() != null; 

@ ensures !( \ result ). equals ("") ; @*/ 
public String format() { /* ... */ } 



,6 } 



Figure 1: Class PositivelntegerData 



pre-conditions and strengthening of post-conditions. Transformation of object-oriented programs with 
formal contracts has already been addressed in a rather informal way iflOll . 

A catalogue of laws (primitive transformations) to deal with Java programs annotated with JML has 
been proposed in (9), which specifies about 80 laws. Here we present one law that deals only with JML 
specifications and two JML-aware Java laws that deals with attributes and methods, respectively. A law 
that only deals with JML can impose conditions only on JML elements present in the program, whereas 
JML-aware Java laws involve both JML and Java elements for stating conditions. The three laws we 
present here are catalogued in Q. 

In this paper, we define laws (Section [3]) of object-oriented programming for Java that are aware of 
specifications written in JML, which we describe in Section [2) The laws we present here and other ones 
present in a more comprehensive catalogue [9l were applied to refactoring a JML-specified version of 
a core module of a Manufacturing Execution System (MES) [22]. In Sectional we present proof of 
soundness regarding the JML parts of two laws. We present an example of program transformation by 
means of laws in Section [5] Final remarks appear in Section [6l 

2 The Java Modeling Language 

The Java Modeling Language (JML) is a behavioral interface specification language (BISL) lfl6l [T4l 
tailored to Java ifTTTl . Thus, JML serves to describe names and static information that appear in Java 
declarations and how they act, how they behave. JML specifications are written in the form of special 
annotation comments that are inserted directly in source code of programs. These comments must begin 
with an at-sign (@) and can be written in two ways: by using //@ ... or /*@ ... @*f. 

In Figure [TJ we present the class PositivelntegerData that represents positive integers. We intro- 
duce an instance invariant (Line 13, which is a predicate that is true in all visible states of objects of a 
class [16]. The invariant in the example has private visibility and establishes that the attribute value must 
always be greater than -1. 

JML uses the requires clause to specify the obligations of the caller of a method, what must be true 
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Law 1 {move invariant to superclass) 
class B extends A { 
ll@ invariant 

ads cnts mds 

} 

class C extends B { 
1 1@ invariant \]/\ && 
cnts' mds' 
\ 

where 

if/2 - this instanceof C ==> iAi m 
provided 

(<-») super does not appear in ip2- 
(—*) <A2 does not contain occurrences of model fields declared in C, nor uncast occurrences of this. 

□ 

to call a method. For instance, the precondition of the method registerValue requires the value of the 
Integer object to be registered to be greater than -1. 

A postcondition specifies the implementor's obligation, what must be true at the end of a method, 
just before it returns to the caller. In JML, the ensures clause introduces a postcondition. For instance, the 
Line |7] introduces a normal postcondition that asserts that the final value of the Integer object we register 
is the same as the one the method receives as argument. The JML modifier pure (LinefTTT) indicates that 
the method doesn't have any side effects and hence can appear in specifications. In JML, the keyword 
also indicates that a method is extending the specification it inherits from its supertype. 

3 Laws 

Our laws extend object-oriented programming laws from other works [3] |U |5] |7J WTi . The laws are 
written in an equational style. Each side of the equation corresponds to a template of a well-formed 
program. Programming laws, in which left-hand and right-hand sides are related by equality, are a 
concise presentation of a pair of laws. These laws precisely indicate the modifications that can be done 
to a program, stating their corresponding side-conditions. In fact, to apply a law, it is necessary to check 
(syntactic or semantic) side-conditions to ensure that the transformation is behavior-preserving and also 
maintains its well-formedness. We consider that we are dealing with only one package and working in a 
limited open system Q, in which classes of our system can depend on external libraries. 

In Java and JML context, we need to guarantee that source-code continues meeting its specifica- 
tions written in JML, taking into account the semantics of JML specifications along with the notion of 
specification inheritance [13]. Here we present a law for invariants written in JML. 

A JML-annotated Java program has the format cds Main, where cds is the set of all classes of the 
program and Main corresponds to the unique class in the program which has a static main method. 
We use cnts, ads and mds inside a class to represents the class constructors, attributes and methods, 
respectively. We have to emphasize that they may contain the specifications of each constructor or 



~cds,Main 



class B extends A { 

1 1@ invariant tAi && iff 2; 

ads cnts mds 

} 

class C extends B { 
ll@ invariant \fj\; 
cnts' mds' 
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Law 2 {move reference type attribute to superclass) 



class B extends A { 

ads cuts mds 

} 

class C extends B { 
/*© nullable @*/ 

ads' cuts' mds' 



T a; 



~cds,Main 



class B extends A { 
/*© nullable @*/ T a; 

ads cuts mds 

} 

class C extends B { 

ads' cuts' mds' 



provided 

/ML: 

(<— ) D.a, for any D < B and D ^ C does not occur inside specifications of cds, Main, cuts, cuts', mds 
nor mds ' . 

Java: 

(<->) T is not a primitive type. 

(— >) (1) a is not declared in ads; (2) The attribute name a is not declared by the subclasses of B in cds. 
(<— ) D.a, for any D < B e D ^ C does not occur in c<f s, Main, cnts, cuts', mds nor mds ' . 

□ 



method. It is not necessarily Java code only, we can also have the corresponding JML specifications. 

In the laws, we use cds\ - c ds,Main cdsi to denote the equivalence of sets of class declarations cds\ and 
cds2, where cds is a context of class declarations for cds\ and cds2- We need to stress that this definition 
takes into account only sequential programs. We write '— »' to indicate the condition that need to be 
satisfied to apply a law from left to right. Likewise, we use '«— ' to indicate what has to be satisfied when 
applying the law from right to left. We use ' «-> to indicate conditions that must hold in both directions. 

The first law we present (LawQ) allows us to move an invariant ip2 from a subclass C to its superclass 
B. The invariant we want to move only refers to instances of C as we require the invariant to be applicable 
only to instances of class C. To apply this law in any direction, we require that calls to super do not 
occur in fa, since after law application (in both directions) these calls may refer different elements. To 
apply this law from left to right, model fields cannot appear in if/2 and occurrences of this must be cast 
otherwise the elements they refer may not be visible. 

Concerning the soundness of this law, we take in account the inheritance of specifications in 
JML [13], in which inherited invariants are conjoined with locally added invariants. On the left-hand 
side, the invariant fa, which is present in class C, is inherited by the subclasses of C and holds for all 
subclasses. On the right-hand side of the law, the invariant fa is inherited by all subclasses of B besides 
those that are not subclasses of C. For those classes that are subclasses of B, but not subclasses of C, 
the invariant holds because for objects of these classes the antecedent instanceof C fails and the whole 
implication is true, not changing the meaning of any original local invariant that inherits i/^- 

By using LawEl we can move an attribute to a superclass if it is not already declared in the superclass 
and if it does not cause name conflicts. The application of Law|U from right to left, allows us to move an 
attribute downward. In this case, we prevent access to the attribute by the expression this, and we allow 
only accesses to a by C or subclasses of C, including accesses that appear in specifications. 
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In Law|2l we consider only attributes whose type is a reference type. There is another law for moving 
an attribute of primitive type. The reason for having two disctinct laws for dealing with attributes of 
primitive and reference types comes from the nullable keyword in Law 12 In JML, any declaration 
(except for local variables) whose type is a reference type is implicitly declared to be non-null, except 
when one adorns the declaration with a nullable annotation [16]. Thus, by default, JML always checks if 
a not nullable attribute is null in all visible states of the class that declares it. When we move an attribute 
to a superclass, this is not aware about the newly moved attribute and, therefore, this action can cause 
a undesirable behavior. In fact, if one instantiates the superclass, JML will raise an invariant exception 
reporting that the new attribute is null. To avoid this, we force attribute nullability to move it up. Then, 
if one wants to move a non-null a attribute, one needs to introduce nullable annotation before moving 
it. An attribute can become nullable applying a law named make attribute nullable, not presented here. 
Remember that in Java only reference types can be null. 

Law |3] allows us to move a redefined method from a class to its superclass. The proviso concerning 
super is needed because its semantics may be affected when we move it from a subclass to a superclass, 
or vice-versa. We can only move the specification of a method if it does not refer to model fields of the 
class in which the method is originally declared. Furthermore, this expressions may occur in the target 
method specifications only if they are cast. In fact, as in the law the method has default visibility, only 
non-private elements can be referenced in its pre- and postconditions. This is similar to Java: the this 
expression may appear in mbody' if they have a cast and they mention only non-private attributes or 
methods of class C. The right-hand side of Law |3] introduces type tests in each one of the specifications. 
In this way we assure that the original pre- and postconditions of the redefined method of C will only be 
applied to callers that are instances of C or instances of any of C's subclasses. 

Law 3 (move redefined method to superclass: overriden method with non-default specification case) 

class B extends A { 
ads cnts mds 
//@ requires 9\ && fa; 
//@ ensures 6\ && fa; 
1 1@ also 

H@ requires 9 2 && fa{, 
H@ ensures 9 2 && fa 2 ; 
1 1@ also 

//@ requires 9 2 && fa; 
1 1@ ensures 9 2 && fa; 
rt m(pds) { 

if (!(this instanceof C)) 
{ mbody } else { mbody' } 

} 

} 

class C extends B { 

ads' cnts' mds' 

} 



class B extends A { 

ads cnts mds 
1 1@ requires fa; 
1 1@ ensures fa-; 
rt m(pds) { mbody 

1 

class C extends B { 

ads' cnts' mds' 
H@ also 
ll@ requires fa; 
1 1@ ensures fa 2 ; 
rt m(pds) { mbody' 



~cds,Main 



where 

9\ = !(this instanceof C) and 9 2 - this instanceof C 
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provided 
JML: 

(<->) super does not appear in i/^ nor in ij/ T 

(— ») Both if/\ and \p2 do not contain occurrences of model fields declared in C, nor uncast occurrences 
of this. 

Java: 

(<->) (1) super and private attributes do not appear in mbody'; (2) super.m does not appear in mds' 

(— >) mbody' does not contain uncast occurrences of this nor expressions of the form ((C)this).a and 
of the form ((C) this) .m(e) for any attribute a nor method m, in ads' and mds', respectively, with 
private visibility. 

(<— ) m(pds) is not declared in mds'. 

□ 

4 Soundness 

The proofs we present here are only concerned with the JML parts of the laws. Proving the Java part 
is difficult due to aliasing, which can lead to representation exposure problems, for instance. In JML, 
specifications present in a class are inherited by its subclasses, provided they are not private. This leads 
us to two concepts: join of specifications and specification inheritance. 

4.1 Join of specifications 

In a program written in Java and annotated with JML, classes inherit not only attributes and methods 
from superclasses, they also inherit specifications of invariants, methods, history constraints, and initial- 
isation predicates lfT3l[l5l . Concerning methods, a method specification may consist of several specifi- 
cations cases, which are introduced by the use of clauses such as requires, assignable, ensures [ 16 ]. Each 
specification case has a precondition (the default predicate is true) that states when the corresponding 
specification case applies to a call. The keyword also joins specifications cases. When a precondition of 
a specification case holds, the corresponding postcondition must hold also, defined earlier in this section. 
The definitions we present here are taken from [15). The notation T > (pre, post) is related to a specifi- 
cation case of an instance method that type checks when its receiver (this) has static type T. It also type 
checks in contexts where this has some subtype of T. In what follows, we introduce the definition of 
joint JML method specifications ifTBTl . 

Definition 1 (Join of JML method specifications) Let T > (pre' , post') and T > (pre, post) be specifica- 
tions of an instance method m. Let U be a subtype of both T' and T. Then the join of (pre' , post') and 
(pre, post) for U, written (pre' , post') \J U (pre, post), is the specification U >(p,q) with precondition p: 

pre || pre' 

and postcondition q: 

(\old(pre') ==> post') && (\old(pre) ==> post) 

□ 

In Definition [T] the precondition of joint method specifications is their disjunction. The postcondi- 
tion of the join is a conjunction of implications (written ==> in JMLs notation), stating that when a 
precondition holds (in the pre-state), the corresponding postcondition must hold. 
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= [by Definition E]] 

/\{addedJnv u \ U £ super s(Blus)} 
= [by set theory] 

/\{addedJnv u | U e ((super s(Blhs)\ supers(A))U super s(A)} 

- [by definition of conjunction] 

(/\{addedJnv u | U € ((super s(Blhs) \ supers(A)))) A (/\{addedJnv w \ W e supers(A))) 
= [by definition of added invariant in Blhs] 

<Ai A (f\{addedJnv w \ W e supers(A)\) 
= [by Propositional Logic] 

\p\ A true A (f\{addedJnv w \ W € supers(A)}) 

- [by Propositional Logic] 

(Ai A (false => ifrinv) A (/\{addedJnv w \ W e supers(A)\) 
= [by type test for object of type B] 

\p\ A (this instanceof C => ipi nv ) A (f\{addedJnv w \ W e supers(A)}) 

- [by definition of added invariant in Brhs] 

(/\{addedJnv u \ U e ((supers(BRHs)\ supers(A))}) A (f\{addedJnv w \ W e supers(A)}) 
= [by definition of conjunction] 

/\{addedJnv u \ U e ((supers(BRus) \ super s(A)) U super s(A)) 
= [by set theory] 

f\{addedJnv u | U e super s(B LHS )} 
= [by Definition [2]] 

extJnv^ HS 

Figure 2: Proof of LawQ]- case of object of exact type B 



4.2 Specification Inheritance 

Subtypes in JML inherit specifications, besides attributes and methods. First, we introduce some notation 
for type specification. For a type T, the invariant predicate declared in the specification of T (without 
inheritance) is denoted by added Jnv T . For a method m declared in a type T, the notation added spec^ = 
(added -pre T m , added -postJ n ) is the join of the specification cases in type T for m. If m is declared in T 
with no specification and is not overriding any method, then added_spec T m = (true, true), which is the 
default specification in JML. We use supers(T) to denote the set of all supertypes of T (including T) and 
method s(T) to denote the set of all instance method names declared in the specifications of the types in 
a set T. 

Definition 2 (Extended specification) Suppose T has supertypes supers(T), which includes T itself. 
Then the extended specification of T is a specification such that: 

methods: for all methods m e method s(supers(T)), the extended specification of m is the join of all 
added specifications for m in T and all its proper supertypes 

extspec T m - \_\ T {added _spec^ \ U € supers(T)} 
invariant: the extended invariant of T is the conjunction of all added invariants in T and its proper 
supertypes 

extJnt 7 - /\ T {added Jnv u | U e supers(T)) 

□ 

The definitions we present here were introduced in lfl5l and are the ones we use in this paper. 
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ext_spec m 
= [by Definition [2]] 

Ufffs {added spec^ \ U € super s(B)} 
= [by set theory] 

\_\ B HS {added_spec^ \ U € (super s(B) \ super s(A)) U super s(A)} 
= [by definition of join with respect to B] 

(YA B LHS {added-speCm \ U e (super s(B) \ super s(A)))) U B (\_\ A {added _s pec™ \ W € super s(A)}) 

- [by definition of join of specification cases for Bins ] 
(4t\,\old(i]/\_) => 0- 2 ) U s (\J A {added _s pec™ \ W e super s(A)}) 

= [by Prepositional Logic] 

(((/rj A true), \oW(iAi A true) => if/ 2 ) U B (\_\ A {added _s pec™ \ W £ supers(A)}) 
= [by type test for object of type B] 

(0/fi A ->(this instanceof C)), \old(ip\ A ->(this instanceof C)) => fa) 

U B (\J A {added. spec™ \ W e supers(A)}) 
= [by Prepositional Logic] 

((n]/\ A ->(this instanceof C)) V false V false, \old(t]/\ A ->(this instanceof C)) => t/^) A true A frwe) 

U B (U A {«<5?^_5pec^ I W e supers(A)}) 
= [by type test for object of type B and Prepositional Logic] 

((if/\ A ->(this instanceof C)) V ((this instanceof C) A 1/^1) V ((f/n's instanceof C) A 
(\old(>j/\ A -*(this instanceof C)) => 1/^2) A (\old((this instanceof C) A i/^i) => t/^)) 
A(\old((this instanceof C) A i/r'j) => t/^)) L-^ (\_\ A {added spec™ \ W e raper^A)}) 
= [by definition of join of specification cases for Brhs] 

(l_\RHS^ added - s P ec m I ^ e (supers(B) \ supers(A))\) U B (\J A {added _s pec™ \ W e supers(A)}) 
= [by definition of join with respect to B] 

\_\f> HS {added _spec^ t \ U € (super s(B) \ super s(A)) U super s(A)} 

- [by set theory] 

[_\f, HS {added _spec^ \ U e super s(B)} 
= [by Definition |2] 

Figure 3: Proof of Law|3]- case of object of exact type B 



4.3 Proofs 

Here we present proofs for Laws 1 and 3. Both proofs involve dealing with cases associated to the types 
of objects related to the classes that are emphasized in the laws. We present the proof for just one case 
of these laws. The conditions of the laws guarantee that both programs that appeal - in the laws are well- 
typed. Concerning Law |2j it is a law for attributes in which specification inheritance is not taken into 
consideration. 

In Figure [2 we present the proof for the case of Law [J in which the we consider an object of exact 
type B. Notice that in LawQ] on the left-hand side, an object of exact type B has to establish the (added) 
invariant iff\. The added invariant is given by ipy A (this instanceof C => ifri nv ), on the right-hand side. 
For an object of type B, the type test is false and the whole implication results true. The whole effect is 
the same of the invariant of class B on the left-hand side. 

The proof for the case of Law|3]in which we consider an object of exact type B is presented in Fig- 
ure |3] On the left-hand side of this law, the specification case for method m in class B has precondition \p\ 
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1 public class EvenlntegerData { 

2 //@ private invariant value . intValue () % 2 == 0; 

3 //@ private invariant value . intValue () > -1; 

4 private Integer value; 

5 public EvenlntegerData ( ) { value = new Integer(O); } 

6 /*@ requires newValue != null; 

7 @ requires newValue . intValueQ % 2 == && newValue . intValue ( ) > -1; 
s @ ensures getValue() . intValueQ == newValue . intValue () ; @*/ 

s public void regi sterValue( Integer newValue) { /* ... */ } 

10 //© ensures \result != null; 

11 public /*@ pure ©*/ Integer getValueQ { /* ... */ } 

12 /*@ requires getValue() != null; 

B @ ensures !( \ result ). equals ("") ; @*/ 

14 public String format () { /* .. . */ } 

15 } 



Figure 4: Class EvenlntegerData 

and postcondition \p2- On the right-hand side, we enrich this specification case with type tests involving 
the class name C, but with no impacts for objects with distinct types from C. The other specification 
case for method m on the right-hand side also involves a type test, having no effects for classes other than 
class C. 

5 Application 

In this section, we present an example composed of excerpts of Java classes annotated with JML, as it 
is refactored by means of successive application of programming laws. Classes PositivelntegerData 
(Figure \Q and EvenlntegerData (Figure |4| represent positive and even integers, respectively. These 
classes are part of a software that stores and manipulates instances of positive and even integers. 

The class EvenlntegerData (Figure @]) can only hold even positive integers because of the invariant 
written in Line|2] And, to reinforce the invariant, pre-conditions of method registerValue guarantee that 
only even and positive values are allowed. These classes share methods that have the same functionality. 
Moreover, both have an attribute called value to save the integer value of the respective data. To improve 
the design of this program (e.g. by reducing the amount of duplicated code) and to accept new data types 
(e.g. odd integers), we need to change the program in a disciplined way. In what follows, we present a 
guideline that leads to the same structure as obtained by applying the refactoring Extract Superclass (H. 
We do not present all derivation steps, we omit most of them to save space, but each step is accomplished 
by the application of a law. A detailed derivation, with all the steps and their corresponding laws, can be 
found elsewhere 

Our starting point is composed by the classes presented in Figures Q] and |4] We first introduce 
a new class (IntegerData) to be the superclass of the existing classes, by applying Law (class elim- 
ination), from right to left. Then, we change the superclass of classes PositivelntegerData and 
EvenlntegerData to be IntegerData, by applying Law (change superclass: from Object to another 
class), from left to right. We prepare classes PositivelntegerData and EvenlntegerData, for moving 
attribute, invariant, and methods. First, we move the common attribute value to the superclass. This is 
accomplished by the application of a sequence of laws, beginning with Law (change attribute visibility: 
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1 


public class IntegerData { 






1 1 (di r*r*ntp**tpH invariant vpIup i nt 1 hp M ~> 1 • 

f / \? |J l u 1 1 l I t U lllTalldlll ValUC. IHLvalUCl J J. , 




3 


protected Integer value; 




4 

5 


// @ ensures \result != null; @*/ 




6 
7 


public /*@ pure @*/ Integer getValue() { /* .. 

} 


■ V } 



Figure 5: Class IntegerData 



from private to public), which changes the visibility of the attribute value to public, then we change 
its visibility to default by the application of another law. In the sequence, we apply Law [2] to move 
the attribute value from class PositivelntegerData to class IntegerData. This is followed by the ap- 
plication of other laws to eliminate the attribute value from class EvenlntegerData. Then, we move 
common methods to the class IntegerData. First, we apply La.w{move original method to superclass) 
to move methods from class PositivelntegerData to IntegerData; then we apply Law[3]to move re- 
defined methods from EvenlntegerData to IntegerData. Another law allows us to simplify conditional 
commands. After moving the attribute value and methods to the superclass IntegerData, we change the 
invariant of classes PositivelntegerData and EvenlntegerData to be in the format required by LawQ] 
We apply LawUtwice, then we simplify the invariant in class IntegerData and change its visibility. 

In Figure |5j we present class an excerpt of class IntegerData after the application of the 
programming laws that lead to the refactoring Extract Superclass QQ. The final version of the 
PositivelntegerData and EvenlntegerData has no getValue method and does not have the common 
invariant (see Figure [51 Line 13 because, now, they belong to IntegerData. 

In Q, we applied the laws proposed here along with others to ref actor a core module of a Manufac- 
turing Execution System (MES) [ '221 software, which formalizes methods and procedures of production 
in an integrated system and presents data in more useful and systematic way. To control and manipulate 
data dynamically and in a highly configurable way, the MES software is built on top of a Meta Data API. 
We have refactored a JML-specified version of the Meta Data API [9] by applying primitive transforma- 
tions expressed by means of our laws. We applied our laws to refactor code and to accommodate new 
features. For instance, we eliminate duplicate code by extracting a superclass that abstracts the behavior 
of other classes present in the system. This is described by the Extract Superclass refactoring [8]. Other 
refactorings presented by Fowler [8] (for instance, Replace Conditional with Polymorphism and Pull Up 
Method) were also applied to the Meta Data API by means of the proposed laws. 

6 Conclusion 

Object-oriented programming laws were proposed by Borba et al. |3] for an object-oriented language 0. 
They proposed laws for classes and commands; they also define a normal form for object-oriented pro- 
grams written in their language along with a reduction strategy. They demonstrate that the set of laws 
is complete with respect to this normal form. Cornelio O [5j proves the laws with respect to a copy 
semantics [4] and formally justifies, by using programming laws and data refinement, refactoring prac- 
tices documented by Fowler [8]. Silva, Sampaio, and Liu consider object-oriented programming laws in 
a language with a reference semantics |2D . applying such laws to code refactoring. Duarte [7] adapts 
the programming laws initially proposed in [3] [5j for the Java programming and proposes other laws for 
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language features that are not present in the language used in (3JI21. 

In this paper, we proposed laws for object-oriented programming in the presence of a behavioral 
interface specification language. In the laws that deal with source-doce, we treat the transformation 
considering the restrictions imposed by the specifications. These laws are based on programming laws 
from previous work SEHTl that does not consider specifications. We have considered laws that address 
only a subset of the JML's Level constructs fl6l , specially for lightweight specifications. Nevertheless, 
our preliminary focus is to cover most of the JML constructs that form the core notation used in the 
design by contract methodology. We have also applied our set of laws for reducing a JML-specified Java 
program to a normal form [9 ] to address the relative completeness of the set of laws proposed. 

With respect to the order of application of programming laws in program transformation process, 
distinct orders may lead to different results. The conditions for application of a programming law usually 
requires the application of other programming laws, defining that their applications are not commutative. 
To obtain the desired target program, a proper law application sequence must be established. Commonly 
used sequences of applications of laws can be registered as single transformation rules. 

Concerning the refactoring process, we can view a refactoring as a target transformation that can 
be reached by the application of primitive transformations expressed by means of programming laws. 
The process of application of programming laws terminates when the desired structure is reached. 
Cornelio O presents refactorings as rules constituted by a pair of programs, similar to a law, but the 
transformation described is more complex than the one of a law. The program on the left-hand side 
presents the class or classes before rule application; the right-hand side presents the classes after rule 
application. Refactoring rules capture complex transformations. Here we have not presented refactoring 
rules as in [6], but the application of the programming laws we presented here and in Q lead us to a result 
similar to that presented in 0, that is, a refactoring is derived by the application of programming laws. 
Although at this moment our work does not provide a way to transform programs mechanically, it offers a 
more reliable and extensible alternative to address behavior-preserving transformations like refactorings. 
Moreover, since some conditions present in the laws are related to logic proofs, it is necessary to use a 
theorem prover as an auxiliary tool. 

Differently from laws that deal only with constructs of an object-oriented programming language, the 
presence of a behavioral interface specification language requires that we be aware of issues related, for 
instance, to the visibility of specification and code constructs, invariant preservation when introducing 
calls to super and changing a parameter type to a supertype requires introducing casts in occurrences of 
the parameter in specifications. 

As future work, we intend to describe laws to support other JML clauses like initially, constraint, 
represents, and model fields. Also, we intend to work on proofs for the Java parts of the laws based on 
a reference semantics iPTI . 
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